A component is a discrete unit of code that delivers a specified set of services through specified interfaces. Components provide the services that clients request at run time. A stateful component maintains private state resulting from the execution of one or more method calls. Thus, for example, a client application connecting to a component can have a “conversation” with the component that spans multiple method calls. The component can retain state across those method calls.
Building stateful components is a useful approach in application design. Programmers typically write stateful applications that retain state across component method calls. This provides the information necessary for correct and successful execution across transaction boundaries. However, such stateful components have availability and scalability limitations. One problem with stateful applications is the risk of losing the volatile state as a result of component failure when the system or process supporting the stateful application fails. Such a failure typically requires human intervention to repair or restart the application. Service outages can be very long because of this. A conventional response to this problem is to insist that applications be stateless. A stateless application has “no meaningful state maintained between transactions”. The loss of the component state prevents the masking of system failures from clients, and degrades application availability.
In view of the foregoing, there is a need for systems and methods that overcome the limitations and drawbacks of the prior art.